UUCP (UNIX to UNIX CoPy) was developed to provide a simple dialup networking protocol
for UNIX systems. It is most often used today as an e-mail transfer system, allowing
non-networked machines to transfer e-mail easily over a modem connection. You also can use
it for USENET news and access to similar services that do not require a dedicated
connection. UUCP is a two-machine connection between your Linux machine and another
machine running UUCP. You cannot use UUCP as a remote system access system (like FTP or
Telnet), nor can you use it as a standard login because the protocols do not support this
type of interactive behavior. Chapter 24 "Security,"
looked briefly at some of the security problems inherent with UUCP. You should read that
section of the chapter when setting up your UUCP system if you are susceptible to
unauthorized access.
Linux can run any of several different versions of UUCP, most of which are compatible
with each other to a reasonable extent except when it comes to configuration and
installation procedures. Many Linux versions offer you a choice between the Taylor UUCP
version and the HDB (HoneyDanBer) UUCP. You can use whichever single version came with
your Linux software, or, if you have both, you can choose between the two (or use both
versions as the mood strikes you).
Many Linux users prefer the Taylor UUCP implementation. Users who have worked on other
UNIX systems prefer HDB because it is more recent and a little more logical in its file
handling and configuration. If you have a choice, you should probably use HDB. This
chapter looks at both of these versions. (Although even more UUCP versions exist, they are
seldom used under Linux.) The first part of the chapter deals with configuring UUCP, and
the rest of the chapter explains how to use it.
Most of the configuration required for UUCP takes place in the /usr/lib/uucp directory.
UUCP uses several files, most of which need direct administrator modification to be set up
properly. Although the configuration process can seem complex to someone who has never
done it before, only a few files need changing, and each file has only one or two entries.
Because the configuration processes for Taylor UUCP and HDB UUCP are completely
different, this section looks at them separately. You don't have to worry about which
version of UUCP is being run at the remote end of the connection, however, because both
versions can talk to each other (at least that's usually the case) as long as the
configuration files are set up properly.
Some versions of Linux have semi-automated UUCP configuration scripts. These scripts
are more common with HDB UUCP than Taylor UUCP, but a few helpful scripts are available
for the latter. If you have one of these scripts, use it, but do check the files manually
afterwards.
In the follwing examples of configuration processes, the host machine's name is merlin,
and it is being connected through UUCP to another Linux system called arthur. As you go
through the process, take care to enter the information in the same format as the
examples, but don't mix Taylor and HDB UUCP information.
The following list contains the filenames and the primary purposes of the configuration
files for the Taylor UUCP system:
| /usr/lib/uucp/config | This file defines the local machine name. |
| /usr/lib/uucp/sys | This file defines the remote systems and how to call them. |
| /usr/lib/uucp/port | This file describes each port for calling out and its parameters. |
| /usr/lib/uucp/dial | This file describes the dialers for calling out. |
| /usr/lib/uucp/dialcodes | This file contains expansions for symbolic dialcodes, but it is rarely used when a straight-out telephone connection exists. |
| /usr/lib/uucp/call | This file contains the login name and password for remote systems, but it is rarely used now. |
| /usr/lib/uucp/passwd | This file contains the login names and passwords used when remote systems connect to your local machine. This file is used only when uucico is password checking instead of using the login process. |
To make the configuration process easier, this section proceeds with a sample
configuration. You need only modify the entries to suit your own names, telephone numbers,
device files, and so on. You can then repeat the process for as many systems as you want
to connect to.
The first file you need to modify holds your system name and other general parameters.
The file /usr/lib/uucp/config needs a single line entry for your system name, such as this
one:
hostname merlin
The keyword hostname must be first on the line, followed by whitespace (spaces or
tabs)and your machine name. The information in this file may have been completed when you
installed Linux, but you should check the contents to make sure. If your system's name
isn't set correctly, the connection to the remote system won't work properly.
To use UUCP, you must have a system name. For compatibility with most versions of UUCP, keep the name to seven characters or less. Ideally, the UUCP name is the same name you assigned to your host during configuration. The name doesn't have to follow a convention (like the system name used by TCP/IP for Internet access), but if you use other network protocols, keep a consistent name. If you have a domain name (for TCP/IP access), use the first component of the machine's full TCP/IP name as the UUCP name. For example, if your full domain name is merlin.wizards.com, use the UUCP name merlin.
You also need to provide information about the remote system you want to connect to.
The /usr/lib/uucp/sys file holds all the information about remote systems. This file
usually has a few sample entries in it that you can copy or modify. Don't leave comment
marks (pound or hash marks) in the first column or the entries will be ignored. A
/usr/lib/uucp/sys entry for the remote machine arthur looks like the following:
# system: arthur (Bill Smallwood's Linux system) system arthur time Any phone 555-1212 port com1 speed 9600 chat login: merlin password: secret1
The first line in the preceding extract is a comment line. Most system administrators
like to put a comment line in to identify each system. The next lines identify the
different aspects of the remote system, including its name (arthur), times at which it can
be called (Any in this case, meaning no restrictions), the telephone number (including any
area code or special digits that have to be dialed), the serial port to be used for the
connection (in this case, com1), the speed at which to connect (9600 baud), and the chat
script or login process. In this case, the chat script tells UUCP to wait until it sees
the string login:, and then send merlin. Then UUCP waits for the prompt password: and
sends secret1.
Most login scripts require a login and password, and you must place these items in the
configuration file because UUCP doesn't allow interactive sessions. This requirement can
be a bit of a problem because it allows other users on your system to see the login
password for the remote machine. But because only UUCP can use this password, this problem
is not a major concern. Also, you can set the file permissions on the UUCP configuration
files to prevent any system users (other than root) looking into the file.
Not all remote sites need a password for entry through UUCP. For example, some public archives let you log in and retrieve files using the uucp login with no password. Other sites use readily available passwords, such as uucp.
The port name used in the /usr/lib/uucp/sys entry does not have to match a device name
on the Linux system because the file /usr/lib/uucp/port is used to match the entry to a
physical device. This file requires an entry similar to the following for a 9600 baud
modem:
# com1 device port port com1 type modem device /dev/cua0 speed 9600 dialer Hayes
In the /usr/lib/uucp/port file, the name of the port used in the /usr/lib/uucp/sys file
is identified on the first line. The type of connection to be used (usually modem) is on
the next. The Linux device that corresponds to the port name is specified as a device
driver (for many Linux systems this driver can be /dev/modem, which is linked to the
serial port device driver).
The modem connection speed comes next, and it shows the maximum speed of the modem.
Finally, the name of a dialer is entered. This parameter is a throwback to the days when
modems couldn't dial themselves and used another device (called a dialer) to make the
connection. The dialer entry in the /usr/lib/uucp/port file is then matched to an entry in
the file /usr/lib/uucp/dial, which tells the modem how to dial the phone. Here's a sample
entry:
# Hayes modem dialer Hayes chat "" ATZ OK ATDT\T CONNECT
This entry shows the script that the system uses to communicate to the Hayes modem. In
this case, the \T in the command line is replaced with the telephone number to be called.
Some Linux system combine the /usr/lib/uucp/port and /usr/lib/uucp/dial files into a
single entry in the /usr/lib/uucp/sys file that names the modem file directly.
The remote end of the connection (in this case, the system arthur) must have
corresponding entries for merlin. The files are similar with only name, telephone number,
and (possibly) device name and chat script changed. Until both ends are configured
properly, you can't get a connection between the two machines. Some Linux systems with
Taylor UUCP have a utility called uuchk that verifies the syntax in the UUCP configuration
files and prints out summary information. If you don't have the uuchk utility, you can
download it from many FTP and BBS sites.
By default, Taylor UUCP allows a remote system to execute only a limited number of
commands when it logs into your system. Typically, the remote is only allowed to execute
rmail and rnews to transfer mail and news respectively. If you want to allow extra
programs to be executed, add a line to the /usr/lib/uucp/sys file that includes all the
commands the remote system can execute. For example, the entry
system chatton .... commands rmail rnews rstmp rdataupdate
specifies that the system chatton can execute any of the four commands given after the
commands keyword. Note that all four commands must be in the usual search path used by the
UUCP utilities (actually by uuxqt).
If you intend to transfer files between two machines, you must also modify the
configuration files. When a remote system sends a file to your machine, the files usually
should be stored in the directory /usr/spool/uucppublic (some systems use
/var/spool/uucppublic) as a safety precaution. You don't want to allow a remote system to
write files anywhere on your filesystem, or it could overwrite critical system files. The
convention for most UUCP systems is to always use /usr/spool/uucppublic as the transfer
directory.
You can specify transfer and receive directories in the /usr/lib/uucp/sys file. For
example, the following entry for the remote system chatton has been modified to include
specific directories for file transfers:
system chatton ... local-send ~/send local-receive ~/receive
In this configuration, the users on your local machine can send any file that is in the
/send directory under the UUCP directory (~/send, which means that any file to be sent to
a remote system must be transferred there first), and any file incoming from a remote
system is stored in the receive directory under the UUCP directory. If you want to allow
transfers from a user's home directory, you can specify the /usr directory as a starting
point. Multiple entries are separated by spaces, so the entry
local-send ~/send /usr
allows transfers from the /send directory under the UUCP directory or from any
directory under /usr.
The preceding two lines deal only with file transfers requested or sent from your
machine. If you want to enable requests for transfers from the remote machine, you need to
add two more lines:
remote-send /usr/lib/uucppublic remote-request /usr/lib/uucppublic
These lines force the remote machine to request files and send them only to the
/usr/lib/uucppublic directory. Again, you can offer several choices if you want, as long
as they are separated by spaces.
Finally, UUCP allows machines to forward data through other machines, a process called hopping.
In other words, if you want to send mail to the system warlock but can only get there
through the system wizard, you have to instruct UUCP that your local system can get to
warlock through wizard by adding a forward command to the /usr/lib/uucp/sys file:
system wizard ... forward warlock
You should then add an entry for the warlock system that tells UUCP that any mail for
you will be coming back through wizard:
system warlock ... forward-to merlin
The forward-to command ensures that any files returned by warlock are passed to merlin,
the local host machine. Otherwise, UUCP would discard these files for not being routable.
By default, Taylor UUCP does not allow forwarding, and most system administrators should
think carefully about allowing it as the potential for abuse is high.
HDB UUCP is a more recent version of UUCP and its configuration files are different
from Taylor UUCP. In many ways, the HDB configuration is easier than the Taylor UUCP
configuration, although neither is difficult once you know the basic process. Instead of
setting the name of the local system in the UUCP configuration files, you use the hostname
command (see Chapter 17, "System Names and Access
Permissions").
The names of the remote systems are stored in the file /usr/lib/uucp/Systems (some
older versions used the name /usr/lib/uucp/L.sys). Each remote system that will be
connected to the local system has a single line. The format of each line is
sitename schedule device_type speed phone login_script
where sitename is the name of the remote machine, schedule is when the machine can be
connected to the local system, device_type is the type of device used to call the remote
system, speed is the speed (or range of speeds) that you can use to connect to the remote
system, phone is the telephone number of the remote system, and login_script is the script
used when a connection is made (like the chat script in Taylor UUCP). For example, to call
the remote system arthur, the /usr/lib/uucp/Systems file has a line like the following:
arthur Any ACU 9600 555-1212 login: uucp password: secret1
The Any entry in the schedule field tells UUCP that it can call at any time. The ACU
entry in the device_type field tells UUCP to use the ACU (automatic calling unit) defined
in the /usr/lib/uucp/Devices file.
The /usr/lib/uucp/Devices file (or /usr/lib/uucp/L-devices file in some older versions)
contains information about the devices (usually modems) that you can use to call the
remote systems. The Devices file follows this syntax
devicetype ttyline dialerline speed dialer [token Dialer ...]
where devicetype is the name of the device (which should match the device name in the
/usr/lib/uucp/Systems file), ttyline is the device driver to be used for the connecting
port (usually a serial line, such as /dev/tty2a or /dev/modem), dialerline is an obsolete
field left as a hyphen, speed is the speed range of the device, and dialer is the name of
the file that tells UUCP how to use the device. A sample line for a Hayes 9600 baud modem
used to connect on the second serial port of the system might have an entry in the
/usr/lib/uucp/Devices file like the following:
ACU tty2A - 9600 dialHA96
This entry identifies the ACU entry as a 9600 baud connection through /dev/tty2A (the
/dev portion of the name is not needed with HDB UUCP), and it uses a program called
dialHA96 to handle the setup and dialing of the modem. Most popular modems usually have
programs available that set the modem configuration parameters automatically, leaving
Linux out of that process. If a program is not available to handle the modem, you can use
an entry in the file /usr/lib/uucp/Dialers. The format of the Dialers entries is
dialer translation expect send ...
where dialer is the name of the dialer (matching the Devices file), translation is the
translation table to use for the phone number (converting characters where needed to
pauses, beeps, and so on), and the expect and send entries are the chat script to set up
the modem. A sample line in the Dialers file looks like the following:
hayes1200 =,-, "" AT\r\c OK\r \EATDT\T\r\c CONNECT
This entry is for a Hayes 1200 Smartmodem, identified by the name hayes1200, with
translations for the = and - characters, followed by the AT commands used to set up the
modem. These entries are usually supplied in the Dialers file for most popular modems.
Permissions for file transfers are a little more convoluted with HDB UUCP than Taylor
UUCP, as HDB UUCP adds many features for special handling. This section gives you the
fundamentals you need to set up properly. For more detailed information, consult a
specialty book on UUCP; the subject can easily consume 100 pages by itself!
The file /usr/lib/uucp/Permissions handles permissions for remote system access and
file transfers. The general format of the entries in this file is
MACHINE=remotename LOGNAME=uucp \
COMMANDS=rmail:rnews:uucp \
READ=/usr/spool/uucppublic:/usr/tmp \
WRITE=/usr/spool/uucppublic:/usr/tmp \
SENDFILES=yes REQUEST=no
where MACHINE identifies the remote machine's name, LOGNAME is the name the users of
the remote machine use to log in (or you use to log in to their system), COMMANDS are the
commands they can execute on your local system, READ is the list of directories from which
they can read files, WRITE is the list of directories where they can write files,
SENDFILES means that they can send files (yes or no), and REQUEST means that they can
request files from your system (yes or no). Notice the slashes at the end of the first
four lines. These slashes are a typical UUCP convention to indicate that this code is a
single long line broken up for readability.
A complete entry for the remote system wizard shows that it is allowed to both send and
receive files, but only from the /usr/spool/uucppublic directory, and it can only execute
mail and uucp commands (the later transfers files):
MACHINE=wizard LOGNAME=uucp1 \
COMMANDS=rmail: uucp \
READ=/usr/spool/uucppublic: \
WRITE=/usr/spool/uucppublic: \
SENDFILES=yes REQUEST=yes
To prevent the remote system from sending files, change SENDFILES to no. To prevent the
remote system from requesting files, change REQUEST to no.
When UUCP connects to a remote machine, it follows a particular series of steps. You
can better understand the configuration files UUCP uses and the processes that are
involved by following through a typical session. UUCP uses uucico (UUCP Call In/Call Out)
to handle the process of connecting and sending information. You can start a UUCP
connection with the uucico command followed by the remote system name:
uucico -s arthur
When uucico starts, it examines the /usr/lib/uucp/sys file (Taylor UUCP) or the
/usr/lib/uucp/Systems file (HDB UUCP) to see whether the remote system name exists there.
When it finds the proper remote system name, uucico reads the rest of the entries for that
system, including the port to be used. From there, uucico uses /usr/lib/uucp/port and
/usr/lib/uucp/dial (Taylor UUCP) or /usr/lib/uucp/Devices and /usr/lib/uucp/Dialers (HDB
UUCP) to start the modem connection (assuming it is a modem used to establish the session,
of course). When the modem is in use, uucico creates a lock on it so that no other
application can use it (the lock is a file starting with LCK.. and followed by the device
name, such as LCK..cua0).
After the chat scripts for setting up and dialing the modem have been executed and the
remote system is connected, uucico uses the chat script in the /usr/lib/uucp/sys file or
the /usr/lib/uucp/Systems file to log in to the remote system. After the the local system
is logged into the remote system, the remote machine starts up its copy of uucico, and the
two uucico processes establish handshaking. After the handshaking has been established,
uucico goes ahead and handles any transfers that are queued. When finished with the
session, the local machine checks that the remote has nothing further to send, and then
breaks the connection. Finally, uucico terminates.
If your two machines are directly connected(no modems involved in the connection),
through a serial port for example, you can use UUCP as a simple network protocol for file
transfer. The only changes to the configuration files mentioned earlier are in the port
specification. Instead of using a modem device, you specify a direct connection. For
example, in the /usr/lib/uucp/sys file (Taylor UUCP), you would have an entry like the
following:
port direct1
A matching entry in the /usr/lib/uucp/port file would look like the following:
port direct1
type direct
speed 38400
device /dev/cua1
These entries specify the the port that uses the direct connection and the speed of the
connection. The entries in the HDB UUCP version are similar, using the
/usr/lib/uucp/Systems and /usr/lib/uucp/Devices files.
The login scripts that form part of the /usr/lib/uucp/sys or /usr/lib/uucp/Systems file
can be the most difficult part of a UUCP connection to get correct. If the machine you are
logging into is a typical UNIX system, you usually only have to worry about the login and
password prompts. Other systems may require some special handling to gain access. For this
reason, the login script is worth a quick look.
Generally, the layout of the login script is in a pattern-action pair, with the pattern
coming from the remote machine and the action from the local machine. The simple login
scripts shown earlier serve as an example:
login: merlin password: secret1
In this case, the local system waits until it sees the string login: coming from the
remote system, sends merlin, waits for password:, and then sends secret1. You can simplify
the script a little by cutting out extra letters from the remote system, because all you
really need are the last couple of characters and the colon. You could write the script as
follows:
gin: merlin word: secret1
This type of script has a good use. If the remote system sends Login: instead of
login:, the shortened script works and the longer script doesn't.
One useful feature of the uucicio login script is its capability to wait for the remote
machine to reset itself (or start a getty process, more likely). To implement this
feature, you use a hyphen and the word BREAK in the script to tell uucico to send a break
sequence if the remote site doesn't respond in a timely manner. Look at the following
sample script:
ogin:-BREAK-ogin: merlin sword: secret1
In this case, if the remote machine doesn't respond with a ogin: prompt after a short
period of time, the local machine sends a break sequence and waits for the prompt again.
You can use a few special characters in the login script. The most important ones for
most UUCP purposes are the following:
| \c | Suppress sending carriage return (send only) |
| \d | Delay one second (send only) |
| \p | Pause for a fraction of a second (send only) |
| \t | Send a tab (send and receive) |
| \r | Send a carriage return (send and receive) |
| \s | Send a space (send and receive) |
| \n | Send a newline (send and receive) |
| \\ | Send a backslash (send and receive) |
Sometimes you need to use one or more of the characters to get the remote machine to
respond to a modem login. For example, the script
\n\r\p ogin: merlin word: secret1
sends a carriage return-line feed pair before starting to match characters. This action
is usually enough to get the remote machine to start a getty on the port.
Both Taylor and HDB UUCP versions let you specify a time to call the remote systems.
Although the previous examples show Any (meaning the system can be called at any time, day
or night), you may want to restrict calls to certain times or to certain days of the week.
The reason for limiting calls may be at your end (costs, for example) or at the remote
(limited access times during the day, for example).
To specify particular days of the week to allow calls, use a two-character abbreviation
of the day (Mo, Tu, We, Th, Fr, Sa, Su), Wk for weekdays (Monday through Friday), Any (for
any time), or Never (for not allowed to connect). You can use any combination of the days.
The times for connecting are specified as a range in 24-hour format when a time span is
required. If no time is given, the systems assume that anytime during the day is allowed.
Dates and times are run together without spaces; commas separate subsequent entries.
Examples of restricted access times are as follows:
Wk1800-0730
MoWeFi
Wk2300-2400, SaSu
The first example allows connection only on weekdays between 6:00 PM and 7:30 AM. The
second example allows connection any time on Monday, Wednesday, and Friday. The last
example allows connections only between 11:00 PM and midnight on weekdays and any time on
weekends. You can build up any time and date specifications you want. These guidelines
apply to both Taylor and HDB UUCP versions.
The permissions of the UUCP configuration files must be properly set to enable UUCP to
function properly, as well as to provide better security for the system. The files should
all be owned by uucp, and uucp should be the group on most systems that have that group in
the /etc/group file. You can set the ownerships either by making all the file changes
explained previously while logged in as uucp or by setting the changes as root and then
issuing the commands
chown uucp *
chgrp uucp *
when you are in the /usr/lib/uucp directory. As a security precaution, set a strong
password for the uucp login if one exists on your system. Some versions of Linux do not
supply a password by default, leaving the system wide open for anyone who can type uucp at
the login prompt!
Set the file permissions very tightly, preferably to read-write-execute only for the
owner (uucp). Blank the group and other permissions— a read access can give valuable
login information, as well as passwords, to someone. When UUCP logs into a remote system,
it requires a password and login. The /usr/lib/uucp/sys and /usr/lib/uucp/Systems files
contain this information. To protect them from unauthorized snooping, set file ownerships
and permissions as mentioned.
If you have several systems connecting into yours, they can all use the same uucp login
and password, or you can assign new logins and passwords as you need them. All you need to
do is create a new /etc/passwd entry for each login (with a different login name from
uucp, such as uucp1, uucp_arthur, and so on) and a unique password. The remote system can
then use that login to access your system. When you create the new UUCP user in the
/etc/passwd directory, force the user to use uucico only to prevent access to other areas
of your system. For example, the following uucp1 login forces uucico as the startup
command:
uucp1::100:1:UUCP Login for
Arthur:/usr/spool/uucppublic:/usr/lib/uucp/uucico
The home directory is set to the uucppublic directory, and uucico is the only startup
program that can be run. Using different logins for remote machines also allows you to
grant different access permissions for each system, preventing unwanted access.
Carefully control the commands that remote systems can execute on your local machine
through the permissions fields of the local access file. Monitor these fields carefully to
prevent abuse and unauthorized access. In a similar manner, if you are allowing forwarding
of files through your system, control who is allowed to forward files and where the files
are forwarded to.
Most important of all is to ensure that whoever accesses your system on a regular basis
is someone you want to have access. If you leave your system wide open for anyone to
enter, you are inviting disaster. Carefully watch logins, and make sure file permissions
and ownerships are properly set at all times.
Once you have configured UUCP, you can use it to transfer files and e-mail. In order to
use UUCP, you have to know the addressing syntax, which is different from the Internet
addressing syntax. The UUCP address syntax is
machine!target
where machine is the remote machine name and target is the name of the user or file
that you are trying to get to. For example, to send mail to the user yvonne on machine
arthur, you would use the mail command with a username destination:
mail arthur!yvonne
UUCP lets you move through several machines to get to a target. This feature can help
save money on telephone bills or make a much wider network available to you from a small
number of connections. Suppose you want to send mail to a user called bill on a system
called warlock, which isn't in your configuration files but can be connected to through
arthur. If you have permission to send mail through the system arthur (called a hop),
you can send the mail with this command:
mail arthur!warlock!bill
When UUCP decodes this address, it reads the first system name (arthur) and sends it to
that system. The UUCP processes on arthur then examine the rest of the address and realize
that the mail is to be sent on to warlock. If you have permission to forward through
arthur, UUCP on arthur sends the mail through to warlock for you. You can have many hops
in an address, as long as each system you are connecting to allows the pass-through and
can connect to the next machine on the list. For example, the address
arthur!warlock!chatton!vader!alex
sends data through arthur, warlock, chatton, and vader in order, and then to the user
alex. You must specify the addresses in the proper hop order or the address will fail.
This multihop addressing can be very useful if a number of friends have local connections
to other machines, allowing you to easily set up a complex network. The hard part is
usually tracking the names of the systems involved.
The exclamation mark in the address is called a bang, so the preceding address is spoken or written as "arthur-bang-warlock-bang-chatton-bang-vader-bang-alex." Shells like the C shell use the exclamation mark to recall previous commands, so you must escape the bang character with a slash to prevent the shell's interpretation. Addresses then become arthur\/!chatton\!yvonne. This looks funny, but you get used to it.
Depending on how you have your UUCP system set, it may call out to the other systems in
an address whenever something is submitted to it, or if callout times are limited, the
data may be spooled until a call is allowed. You have already seen how to set callout
times in the /usr/lib/uucp/sys and /usr/lib/uucp/Systems files.
A quick caution about relying on UUCP for delivery of information. If the systems that
are being used are not set to call immediately when something is queued, your data can
take a long time to get to its destination. For example, if one of the hops in your
address only calls the next machine in the address once a day, you may have a 24-hour
delay in delivery. This delay can be exacerbated by each machine in the network.
Also, don't rely on the contents of your data sent through UUCP to be kept
confidential. Once your data is on a remote system, any user with access privileges to the
queue could snoop into your data. Ideally, the file permissions will prevent anyone but
the superuser accessing the data, but not all systems keep tight security. If you must
send sensitive data, encrypt it and let the recipient know the decryption key through
another format (not in a mail message).
UUCP deals with all transfers as jobs, a term you'll encounter often when
working with UUCP and its documentation. A job is a command that is to be executed
on the remote system, a file that is to be transferred to or from the remote system, or
any other task that you want performed between the two systems.
Because most utilities, like mail packages, understand the UUCP addresses, you don't
have to worry about e-mail not reaching the proper destination. You usually don't have to
make any changes at all to applications running under Linux to get them to understand the
UUCP address format. In the last section, you saw how you can use the mail package with
UUCP addresses.
You can use any of the usual mail command options to modify the behavior of the
package. For example, to send the contents of the file data_1 to yvonne on system chatton
through the system arthur and tag the mail with a subject heading, issue the command:
mail -s "Data file" arthur!chatton!yvonne < data_1
Most mail packages available for Linux, including X-based mailers, work perfectly well
with UUCP addresses as well as the more common Internet addresses, but you may want to
check before adopting a new mail package.
UUCP's most common use is to transfer files from one machine to another. To transfer
files using UUCP, you use the uucp command. The syntax of this command is as follows:
uucp [options] source destination
The options supported by uucp vary a little depending on the version and type of UUCP
implementation, but most versions support the following useful options:
The default behaviors are usually sufficient for most users, although you may want the
mail options when you need confirmation of an action.
Both source and destination are the names of files or directories as appropriate, much
like the cp command. However, when you are dealing with a remote system for the source or
destination, you need to format the file or directory in valid UUCP address format. For
example, to send the data_1 file from your local machine's current directory to the
directory /usr/spool/uucppublic on the machine arthur, use the command:
uucp data_1 arthur!/usr/spool/uucppublic
Notice that the remote machine name was prepended to the full target directory name. In
most cases, when transferring files to remote systems, you should use the uucppublic
directories as you likely will not have permission to transfer files anywhere else in the
filesystem. Once the file is on the remote system in the /usr/spool/uucppublic directory,
it is up to the remote system's users to find the file and copy it to its intended
destination directory.
If you want to send the same file to the user bill on the remote machine, store it in a
subdirectory called /usr/spool/uucppublic/bill, and send mail to both yourself and bill
when the copy is completed, issue the command:
uucp -m -nbill data_1 arthur!/usr/spool/uucppublic/bill/
To copy a file from a remote machine to yours, you need to specify the location of the
remote machine. Remember you must have access to the directory that the files reside in
(as well as read permission on the file) or have the sender copy them to uucppublic. The
command
uucp chatton!/usr/tmp/bigfile /usr/tparker/
transfers the bigfile file from the directory /usr/tmp on the machine chatton to your
/usr/tparker directory.
UUCP allows you to use wildcards, although you must escape them in quotation marks to
prevent the shell misinterpreting them. For example, to copy all the files starting with
chap on the remote machine warlock's /usr/bill/book directory (assuming you have
permissions) to your own /usr/bigbook directory, issue the command:
uucp "warlock!/usr/bill/book/chap*" /usr/bigbook/
You can specify hops in the machine transfers by adding the extra machine names to the
command. This task requires permissions to be set on all the machines that the hop will
pass through and is seldom done. You can transfer files from one remote system to another
by specifying their names on the command line, as in the following example:
uucp arthur!/usr/lib/uucppublic/bigfile warlock!/usr/lib/uucppublic/
This command sends the file from the arthur system to the warlock system. In most
cases, the users on either of the two remote systems would issue the commands, relieving
some of the file permission problems.
You can check on the status of transfers that are scheduled but haven't taken place yet
by using the uustat command. When you issue the uustat command, all the UUCP transfers
that are queued are listed. The format of the list is
jobID system user date command size
where jobID is the identification number of the UUCP job, system is the name of the
system to transfer to (the first system in an address when multiple hops are taking
place), user is the username who queued the job, date is when the job was queued, command
is the exact command to be executed, and size is the size of the transfer in bytes.
If you issue the command as a user (not superuser), only your jobs are listed. The
superuser lists all jobs that are queued. If you are logged in as a regular user and want
to see all jobs, use the -a option:
uustat -a
To cancel a queued job, use the -k option of the uustat command along with the jobID.
For example, to cancel jobID 17, issue the command:
uustat -k 17
You can only cancel your own jobs, unless you are logged in as superuser, in which case
you can cancel any jobs.
UUCP is quite easy to set up as long as you follow the rules. Once the configuration files are properly set, UUCP can transfer e-mail, news, and files to other systems. Using UUCP to transfer mail and files is as easy as using the usual mail and cp commands. Although UUCP is less popular nowadays because of the LAN craze, it does provide a simple, very low cost network for those who need to connect only a couple of machines. It's also great for connecting your machine to your friends' machines, allowing e-mail back and forth, and making your Linux system seem like a well-connected workstation.
